Healthcare Resources - Zergo Report

Cryptome DVDs are offered by Cryptome. Donate $25 for two DVDs of the Cryptome 12-years collection of 46,000 files from June 1996 to June 2008 (~6.7 GB). Click Paypal or mail check/MO made out to John Young, 251 West 89th Street, New York, NY 10024. The collection includes all files of cryptome.org, jya.com, cartome.org, eyeball-series.org and iraq-kill-maim.org, and 23,000 (updated) pages of counter-intelligence dossiers declassified by the US Army Information and Security Command, dating from 1945 to 1985.The DVDs will be sent anywhere worldwide without extra cost.

1 October 1997
Source: http://www.cl.cam.ac.uk/users/fapp2/healthcare/zergo.html

Thanks to Fabien Petitcolas, Ross Anderson and David Wagner, with help from a version of this report from Bruce Tober.

See: Comments on this report by Ross Anderson.

See also DTI on the regulatory intent concerning use of encryption on public networks

Typos corrected by JYA. Note the pages missing, in red.
Contributions of the missing pages welcomed. E-mail to <jya@pipeline.com> or fax hardcopy to (U.S.) 011-212-799-4003.

Healthcare resources
Zergo Report

This is a scanned version of the report done by Zergo for the NHS. Please allow errors due to OCR.

Preface

This report has been accepted by Ministers and by the NHS Executive The report confirms that provision of cryptographic services for NHS-wide use would be costly and complex Acceptance of this report only implies commitment to start piloting. Further action will depend on the outcome of the trials.

The report is being made available to individuals and bodies known to be interested. Further copies may be obtained from:

Department of Health
PO Box 410
Wetherby
West Yorkshire
LS23 7LN

Tel. 01937 840250
Fax 01937 845381

Management summary

Zergo Limited has been commissioned by the Information Management Group of the NHS Executive (IMG) to undertake a study looking at the ramifications of using encryption and related services across the NHS-wide Network (NWN) also known as the NHSnet. The principal requirement, which is for the confidentiality of Person Identifiable Data, is assumed. The study is to consider the ways in which encryption could be provided across the network, in the context of those networked systems that exchange Person Identifiable Data. It is then to recommend how encryption could best be provided to meet the NHS's requirement given the current relevant technical and business strategies, and to advise the NHS on the ramifications of that approach including the likely costs and benefits that would arise. Finally, it is to consider in what ways the encryption approach could be extended to provide other related network security services in a cost-effective manner

The main results of this study are that

the needed technology has recently become available to allow encryption to be provided across the NHSnet in a versatile and beneficial manner, and in a way that is responsive to need and cost. Importantly, the use of encryption by some systems for some data does not require the use of encryption by all systems or for all data
the NHS's needs should be addressed by a family of related encryption products built on the Red Pike encryption algorithm. This algorithm has recently been made available to the NHS by CESG, the National Technical Security Authority within HMG
the introduction of encryption facilities will not be a panacea for solving all the information security problems associated with networking NHS systems
the encryption facilities could be used in a mariner which is highly automated and manageable
the implementation process will be by no means simple There are a number of management and technical issues that will need to be addressed within the implementation programme for the encryption facilities. However, an approach is identified that will reduce the associated risks to a manageable level
the recommended facilities should be readily extendible to support the provision and use of related cryptographic services such as Digital Signatures to prevent unauthorised tampering with the communicated data and to link unambiguously the communicated data to the identities of the parties involved in its exchange
the NHS will need to develop a key management infrastructure to sit across the many different systems that will become encryption-enabled. This infrastructure will require one or more Trusted Third Part, (TTP) management centres, though the staffing requirements for these will be small
the potential benefits will be considerable if encryption is found to be a precondition for extensive use of the network services by clinicians. The expected costs are small in comparison with the costs of the IT facilities with which they would be used, and in proportion with the expected costs of networking
the main manpower costs for the NHS will relate to the running of the pilot and subsequent implementations. For these, the MIS will need to provide a few tens of man-years of internal staff resource. There is the potential for approximately £ 250,000 worth of external expert security consultancy to assist in these programmes. The day to day operation of the TTP(s) will require only a handful of staff, at most eight full time equivalent staff. There will not be the need for many thousands of users to be trained up before encryption can be used
the possible equipment costs for introducing encryption across the MISnet could well be in the range £ 15M to £ 20M, spread over an implementation programme spanning several years. At the end of this programme, the annual on-going costs could be expected to be in the range £ 2.5M to £ 3M.

The study considers the range of contexts with which encryption might be appropriate and concludes that there are many. From this it goes on to deduce that what is required is a small family of related encryption products rather than just a single product. The family of products would allow encryption to be provided according to the needs of individual systems. Encryption could be provided either as part of the user's application or in conjunction with the user's networking facilities. It could be provided for those systems that require it without it being necessary for all systems to use it regardless of need. And the needed central management facilities (one or more TTPs - trusted facilities to manage cryptographic keys on behalf of users) would be readily scaleable, allowing an initially small management facility to be established, and for this subsequently to take on the support of a growing community of users without the need for a large central management or Head Office team.

There are a number of established providers of the needed types of security products that should be able to support the NHS's needs, allowing the NHS to enjoy the benefits of a competitive marketplace. The central management facilities could be provided in a number of ways including either as a bespoke development for operation by the NHS or as a Private Finance Initiative for operation by an external trusted third party service provider.

The study recommends that the encryption facilities should be implemented in a staged manner which allows the management and technical issues to be addressed in a controlled and steady way. A staged pilot should be defined to prove the feasibility of using encryption across the NHSnet, to test its use with a number of different types of system, and to allow the measurement of a number of technical and management parameters. After consideration of the results of the first stage of the pilot, a strategy should be defined for implementing the encryption facilities in stages to cover both new and existing networked systems according to priority and need. It should be expected that implementations could be started before all the stages of the pilot have been completed. The implementation program is likely to extend over a number of years, though the benefits from using encryption will be felt from the first stage of the implementation. An outline of the steps that will be needed for the pilot and subsequent implementations is given within this report.

Introduction

The NHS is in the early stages of implementing the NHS-Wide Network (NWN) also known as the NHSnet. The NWN has an associated NWN Security Policy and Codes of Connection, and guidelines on the use of access controls on the network. The network does not presently have any general provision for the use of encryption or related cryptographic services for protecting the confidentiality of data transmitted across the network.

However, a number of technical barriers which have made the use of encryption by the NHS difficult in the past have been lowered recently. These include general product developments in the cryptography marketplace, greater experience in the security management of large and diverse networks, and a change in policy and approach by the relevant government department (CESG - the Communications-Electronics Security Group). These have, amongst other things, shown that encryption can be employed by organisations which are large and diverse and which do not follow a strictly hierarchical organisational structure.

As a result, and mindful of the possible need for such services, the NHS Executive in September 1995 commissioned Zergo Limited to undertake a study to investigate the ramifications of providing encryption and related services across the NWN.

The objectives of the study were:

to examine the contexts in which encryption and other data security services would be required for the exchange of Person Identifiable Data across the NWN
to describe suitable techniques for implementing these security services
to identify and describe the many different impacts the recommended facilities would have on the various parties involved in the use and operation of the NWN, including the likely benefits and expected costs for each stakeholder
to identify and discuss an implementation approach appropriate to the particular environment of the NWN where the end user organisations enjoy a great deal of autonomy.

(Contents description of rest of report, plus terms of reference)

The context for security services

Security Threats

Current concerns about NWN security are centred on two main threats:

the possibility of unauthorised individuals logging on to the network
the possibility of eavesdropping on network traffic.

The primary concern is that, by either of these methods, an attacker might gain access to confidential Person Identifiable Data.

The threat of unauthorised access to the network is being addressed through a number of controls including strong user authentication methods, and these are the subject of other work. Addressing the remaining eavesdropping threat is the subject of the present study, and it is this which leads to the consideration of encryption as a possibly suitable countermeasure. However, encryption, if used appropriately, does have further value in that it can help prevent unauthorised access to networked systems or data. Unauthorised users would find themselves unable to access these systems because they would not possess the correct decryption keys. Again according to implementation, authorised users might obtain some protection against accidental or deliberate misrouting of data (posting confidential data to an open discussion group, sending a confidential e-mail to the wrong e-mail address) if the (unintended) recipient did not posses the correct decryption keys.

It can be argued that that the type of Person Identifable Data which will shortly be passed over the NWN has in the past been transmitted between healthcare professionals by mail or by telephone, and that similar risks of disclosure have long existed. However, it is important to realise that the use of electronic means of communication does introduce new security threats and security risks. For example, it is relatively easy to automate the process of sifting through a large amount of text-based message traffic searching for key words and information particular interest. This kind of eavesdropping is a threat to communicated Person Identifiable Data and is less laborious than that of steaming open mail or tapping telephone conversations. The types of cryptographic techniques needed to counter network eavesdropping can often be used to deal with a number of other data security threats which also exist on the NWN, though those requirements may not be as much to the fore as eavesdropping These include:

deliberate alteration of a message for some malicious purpose such as fraud or sabotage
the introduction of messages by one user purporting them to have been sent by another (spoofing, for example to obtain confidential data by deception)
repudiation of a message sent earlier by the sender (for example, the potential disowning of a negligent pathology result).

However, there are a number of other threats that will not be addressed by the use of network encryption, for example, the abuse of access by authorised users. As has been said, these other threats are being addressed separately by the NHS Executive, and they are not dealt with within the scope of this report.

Communications Contexts

The conclusion drawn from the study of communications contexts by C International was that there is, or will be, a wide range of information flows between a wide range of communicating entities where unauthorised disclosure could, potentially, give rise to significant and undesirable impacts

Looking closer across the many dataflow contexts that need securing, the characteristics of the sum total of the data flows are that it:

can involve almost all users, each communicating, potentially. with many others
can touch almost any link of the NWN
will involve many systems, both national and local
will involve many different IT platforms, some of which will be relatively new high-specification platforms but most of which will be relatively low-specification platforms
will involve a variety of higher level communications protocols.

Messaging (including E-mail) is the largest single type of NWN communications context and is expected to remain so for some time. However; other types of communication (file transfer; interactive system access, tele-medicine) are significant and will become more so with time. Many users are expected to access the NWN via dial-up links. Hence, it is important that any solution adopted should be capable of protecting these. The NWN will also be used for broadcast traffic (though, by its nature, most of the broadcast traffic will not be confidential), and it is important that any solution adopted should be capable of protecting this.

Also, with time, it is expected that the development of more sophisticated health care systems will lead to the exchange of more comprehensive and, therefore, more sensitive clinical data over the NWN. New applications of networking in the health environment are already appearing which also bring further confidentiality demands, for example remote consulting. This particular example would require confidentiality protection of multiple synchronised channels, and possibly of digital mobile radio channels, carrying voice and image as well as data.

From our study of the characteristics of the communications contexts we derive the conclusion that if encryption is to be effective in preventing eavesdropping and in preventing Outsiders not equipped with the necessary technology and encryption keys from communicating with networked systems, then it should be capable of being made available at all endpoints in the network and in a form capable of protecting any data transmitted to any other endpoint.

What is required to achieve this is not so much a single encryption product as a general encryption service based upon a family of encryption products, a service which can be used to protect any type of communication involving any pair or group of NWN network endpoints The protection needed will be against eavesdropping and to prevent anyone, either insiders or outsiders not equipped with the necessary encryption facilities and keys, from communicating with networked systems.

(Three pages omitted)

Choice of Encryption Algorithm

A number of encryption algorithms, public domain and proprietary, exist. However, strong encryption algorithms and not available for general use, and those algorithms which are available for general use (for example, in the form of commercial off-the-shelf products) are not regarded as adequately strong for the protection of Person Identifiable Data. Consequently, the selection of a suitable encryption algorithm is not, in this situation, straightforward.

Given the national interest in the proper protection of Person Identifiable Data, the advice of the National Technical Security Authority, CESG, has been Sought on the choice of encryption algorithm. CESG's advice is that, in the case of the NHS, there are security benefits to be obtained from avoiding the use of encryption algorithms which are in the public domain. CESG has recently been able to make available to the NHS (and to others, including non-financial sector Organisations) a suitable non-public domain algorithm known as Red Pike. This encryption algorithm is very new, but there are already a small number of products available on the market which use it, and a wider range of products which use related algorithms and which could quickly and simply be modified to use Red Pike Consequently, the NHS need not fear that it might become locked in to a single product or single supplier if it were to adopt Red Pike as its preferred encryption algorithm.

For the suppliers of encryption products, the NHS would represent a large user community, and this size of potential market would encourage the development of an active and competitive market in Red Pike products. Also, the NHS is not alone in wanting to encourage the development of an active Red Pike marketplace. Many large international organisations outside the Financial Services Sector are in need of similar encryption facilities. And, at the same time, HMG has a number of initiatives currently underway which will lead to the development of Red Pike-based systems. For example, a CCTA-driven initiative to allow suppliers to government departments to submit proposals electronically, and an Inland Revenue-driven initiative to allow small businesses to file Tax returns electronically. These organisations should add their weight to the NHS's to encourage a wide range of commercial off-the-shelf (COTS) products to be developed.

Technical Approach

In light of the conclusions drawn from studying the many dataflow contexts described in the previous section of this report, and in view of the NHS's networking strategy, the NHS's network security strategy should, in the large, favour providing the encryption facilities to the host system whenever possible and, only if justified on a case by case basis, provide it directly on the network itself.

(2 pages omitted)

This approach means that:

for some applications, such as national applications, there will need to be central policy defining where and how the encryption facility is to be used
for other systems, there will need to be standards or guidance developed to help the users determine if the cost of encryption is warranted given the risks. As these will impact suppliers to the NHS, the NHS Executive should have an interest in what standards or guidance are provided. The NHS Executive may wish to coordinate and drive the development of these standards or guidelines
for general use encryption packages, the users may wish to seek guidance on when to use encryption and when not.

New applications will be able to incorporate the encryption facilities they need, in the form that is most appropriate to them, from the start within their design Hence, for each new system, the cryptographic sub-system could be designed according to business and technical needs, and in line with the applicable NHS cryptographic Standards or guidelines. The use of NHS cryptographic standards will channel the systems developers towards the reuse of a standard set of cryptographic products.

In the case of existing applications that might need to be upgraded to use encryption, it will be necessary for developers to incorporate the encryption facilities in to the existing system following the analysis of a business case comparing the perceived needs and expected costs.

Trusted Third Parties

With Red Pike, as with any symmetric encryption algorithm, for two parties to be able to exchange encrypted traffic they need to have a way to establish and manage the shared keys. Again, the advice of CESG was sought about the possible need to interwork with any future national key management infrastructure. CESG's advice was most helpful and, while not leading to the introduction of any specific functionality into the recommended NWN key management infrastructure, has influenced the recommendations made in this report so that they allow for this possibility.

Given the size of the NHS community and the need for the simplest of means for initialising the users' encryption facilities, the NHS will need to develop a key management infrastructure which is built on the use of what are known as asymmetric methods, and using one or more Trusted Third Party (TTP) facilities.

(One page missing)

Key Management Infrastructure

There are two options for the type of technology that could be used for the key management infrastructure, RSA technology or Diffie-Hellman (D-H) technology (see Appendix C for a description of these terms and technologies). The technology that Zergo recommends the NHS should use is the D-H technology. This will allow the NHS to reserve its options regarding the possibility of interworking with any future national key management infrastructure. It is highly likely that any such national infrastructure would be based on D-H technology. It is almost certain that it would not be based on RSA technology. In all other significant aspects, including intrinsic security strength, the two technologies are equivalent. Hence, a D-H key management infrastructure is the more strategic of the two available options.

A D-H key management infrastructure would not preclude the use of other algorithms, for example RSA, if that were needed for interworking with other systems such as those in use in other European countries. A D-H based infrastructure could easily be extended to support DSA (a standard Digital Signature algorithm) based functions which could then be used for the generation of suitable RSA (or, for that matter, DSA) key certificates.

The actual design of the NHS's key management infrastructure will emerge in the early stages of the proposed pilot programme (see Section 5.1). The first stage of the pilot will carry the main burden of establishing the core key management infrastructure. Hence, the design for this will need to be covered early in the pilot. Though it would not be wise or appropriate to design the key management infrastructure within this study, the expected general shape of the infrastructure can already be sketched out (see Appendix C).

Short-Term or Interim solutions

It is acknowledged that the strategic approach recommended in this report will require some time to be piloted and implemented, and that this would not provide all users with encryption capabilities in the immediate term. For those users that have a more urgent need to use encryption, other, interim options are available. These could be used within the NWN on a case-by-case basis and would not inhibit or interfere with the strategic developments as they come on stream. However, they would not allow the users to interwork with the strategic approach as it was increasingly implemented. They should, therefore, be seen as interim steps for the short term, and it should be expected that they would need to be replaced at some time in the future when interoperability with other strategically protected end-systems was required.

(Three pages missing)

Implementation issues

A strategy will need to be developed for supporting the introduction of encryption facilities into new and existing applications, as described below

suppliers of existing MIS applications may need encouragement to integrate cryptographic security into their systems - perhaps through the existing Accreditation process
injecting requirements for added cryptographic security into projects already running as Private Finance Initiatives may disturb the underlying business case and thus be resisted by the developers, or lead to a re-pricing of the service provided
the additional costs of implementing cryptographic security may impair the business case for some systems which do not have the prospect of a large customer base. It may never be cost effective to migrate some legacy systems (older generation systems) or dumb systems to incorporate cryptographic security.

The legal, commercial and organisational issues surrounding the creation of Trusted Third Parties will have to be investigated. These will need to include.

the Terms of Reference for establishing the TTPs
the need for or form of charging for the TTP's services
legal conditions under which TTPs will be able to release information under their control or care
to whom TTPs will release each category of information
the liabilities that will fall to the operators of the TTP, to the NHS centrally and to the NHS user in the event of a failure in the TTP's controls
what kind of entity could be acceptable as a TTP, e.g.:
- NHS central organisation
- A Trust
- Specialist commercial security organisation
- Government department

The pilot will allow these TTP issues to be exercised and will help the NHS to determine its long term position with regard to the provision of TTP services. From these and related considerations, the NHS will then be able to determine its requirements for controls on the TTPs. The contracting of TTP services will then need to be framed with attention being given to the relevant legislative frameworks as they exist within English law.

Technical Issues

As Red Pike, the recommended encryption algorithm, is not yet well known and as a consequence has not yet achieved wide acceptance in the public domain it should be subject to independent review by an expert who is acceptable to the commercial and public domains as well as to the owners of the algorithm, CESG. The objective of this will be to obtain authoritative assurance that no agency external to the NHS could reasonably decrypt data which has been encrypted by the NHS. This review will be an important part of the NHS managing the presentation of its encryption approach. It will also give the NHS confidence that its interests are being properly represented by CESG when it advises on the use of Red Pike.
The newness of Red Pike means that, though there are already a number of suppliers that can provide Red Pike cryptographic tools, there is currently only a limited range of products available. However, given the size of the NHS market alone, as the NHS makes these suppliers aware of its needs it can expect that appropriate products will be developed to meet these needs. This need for new product development will add to the technical risks of developing NWN encryption. However, Zergo believes that the additional risk will be slight given that Red Pike has been designed to allow it to be used in conventional products as a simple replacement for conventional encryption algorithms.
Some of the systems used by the NHS may also be marketed by their suppliers for use in other countries in addition to the UK. Suppliers will be looking for architectural solutions to adding encryption to their products, which are capable of adaptation for use in those countries. Solutions based on high-level APIs, International Standards or de-facto standards, and modular cryptography, as recommended here, will likely be more acceptable in these situations.
Early in the development of the NWN encryption pilot it will be necessary for the NHS to develop a detailed Key Management design for the core of the key management infrastructure. This will be highly specialised work requiring expert cryptographic assistance. Zergo advises that the NHS should, at this stage, also seek further input from CESG to confirm that the resultant scheme is of a sound design. CESG is expected to be strongly supportive of the NHS's development of a key management infrastructure and can be expected to offer its assistance in this and various other stages of the pilot development.
(One page missing)
CESG has not taken detailed performance measurements for Red Pike as these would vary according to the application and platform concerned. The NHS will need to obtain precise performance figures applicable to the range of IT platforms that the user community is expected to use, preferably before the design of the pilot is commenced. However; having seen a description of the algorithm, Zergo would expect that its performance will be acceptable and, indeed, has the capability to outperform many existing encryption algorithms such as DES.
The secure storage of secret cryptographic keys win have to be addressed for each of the different types of end-site attached to the NWN. In situations where all the cryptographic functions are implemented in software to reduce cost, the storage of secret keys on disk always brings some residual risk of disclosure or unauthorised access to the keys, even when the keys are themselves stored encrypted under some other key. An alternative way to protect the keys is to store them on some kind of removable medium or token. It is expected that, increasingly, NHS users will be using smart cards for system access and then the user's keys could be stored on the smart card itself instead of on the user's workstation. A number of other such options can be identified. In all cases, it is important that, for any system, its detailed design gives adequate consideration to the issue of recovery from the loss of such a token.

Once the implementation has started and before it has completed there will be a considerable period of time during which some but not all of the end users will have been encryption enabled. This raises an issue to do with managing the interworking between users and applications where some will and others will not be equipped with encryption facilities. The staged implementation programme where whole systems are brought on-stream one at a time should minimise the size of this issue. It may become necessary in some situations to allow the user the discretion to determine whether or not a message should be encrypted depending on whether the recipient is capable of decrypting such a message. In practice, each situation will have to be examined and appropriate choices will have to be made on a case-by-case basis.

(12 pages missing)

Benefits

Each stakeholder will obtain some benefits from the use of encryption on the NWN, though these may well be different for different stakeholders.

Patients

Patients will benefit from the actual increase in security on the N~, and the level of benefit will increase in time with the degree of implementation achieved. As Person Identifiable Data exchanged over the network is increasingly protected, the risk to the patient of its disclosure and the possibility of embarrassment or consequential financial penalty, will fall. Patients will also benefit from having increased confidence in the practices of the MIS, and from the increased quality of service provided by the healthcare professions that will come with the increased automation and networking of MIS systems enabled by NWN encryption.

Clinicians and health care professionals

These will benefit from being able to make wider use of the NWN so that they achieve a reduction in bureaucracy and give better service to their clients. Lack of encryption may have been a barrier to this in the past, and this need no longer be the case with the introduction of encryption-enabled systems. The level of benefit will increase with the extent of the implementation of the encryption facilities. To the degree that the encryption facilities are used to provide services other than network encryption, the clinicians and health care professionals would be able to protect confidential information in their care against other threats. For example, the use of encryption to protect data stored on PCS or hand-held equipment would protect the data from disclosure if the equipment were lost stolen.

Health Care Managers

Health Care Managers are responsible for the end-systems and are, amongst other things, responsible for ensuring that their systems are adequately secure for the purposes to which they are to be used. To the degree that their systems are exposed to networking security risks and these risks are not otherwise covered by other countermeasures, the addition of encryption to the NwN will provide them with an effective ~d to manage those risks. Encryption could be added in a way that was responsive to the business need and technical environment. They will then be able to direct their attention to addressing the other non-networking security risks to their end-systems, and to fulfilling their responsibility to manage the full profile of risks faced by their systems. Health care managers will also benefit from being able to develop systems and automate processes that could not have been developed or automated without the improved security facilities that would now become available.

The Data Protection Registrar

The DPR will wish to be assured that Person Identifiable Data is protected when transmitted across the NWN. Neither the current Data Protection legislation nor the recently agreed EU Data Protection Directive mandates the use of encryption; that is a matter of national interpretation. However, it should be expected with confidence that the DPR would be pleased to see that personal data was encrypted on the NWN.

The NHS Executive

The NHS Executive would benefit in a number of ways from the introduction of encryption on the NWN.

Overall, the level of security risk faced by MIS systems will be reduced as network security disclosure risks are reduced.

The provision of encryption will encourage the wider use of the NWN for mainstream applications. Hence, encryption will allow the NHS to realise more fully the considerable benefits associated with the ~w~. Also, having the encryption and related capabilities in place will be an important enabler of future IT initiatives allowing new systems opportunities to be realised.

The API approach to encryption proposed as pan of the recommended approach can easily be extended to provide the functionality needed to deliver message integrity protection, user authentication and message source authentication. Encryption in a variety of forms can also be used to support the stronger enforcement of access control across systemS, though care must be taken to ensure that it does not interfere with or run across the desired access control systems. Consequently, the strategic approach provides the MIS with a highly cost-effective manner of addressing these further security concerns.

Depending on the particular form of their implementation, some of the technologies proposed to satisfy the need for encryption on the NWN can be used to address security needs which exist outside the NWN, including the encryption of data transmitted over other networks such as local LANs, the encryption of data stored on hard disks, the management of cryptographic keys for non-NwN systems, and so forth. Consequently, again, the strategic approach provides the NHS with a highly cost-effective manner of addressing these further security concerns.

Though the study here has focused on the protection of Person Identifiable Data, there is nothing in the technology or approach recommended that restricts its use to this type of data. The encryption and related facilities could be used to protect any sensitive data exchanged across the NWN including contracting and management data.

The result of following CESG's advice in the choice of encryption algorithm is that (subject to independent confirmation of the algorithm's Strength - see Section 5.2 above) the level of security provided on the NWN will be higher than that in many conventional Banking systems. This wilt help the NHS to counter any criticism of the NWN's security approach in so far as confidentiality is concerned.

Implementation

Planning and Outline Specification

Following the satisfactory completion of the preliminary confirmations, the NHS will be able to advance into the planning of its implementation strategy. It will need to.

Confirm its strategy for cryptographic algorithms and key management in the light of the results of the above StepS.
Decide, what controls it might wish to have put on access to keys held at the TTPs.
Build a Project Strategy that covers staged piloting and staged implementation. Decide on the pilot prOjects and determine whether to use the Clearing Service for the first stage of the pilot. Decide on an initial outline implementation programme. This can carry implications regarding the preferred order of priority for protecting NHS systems using the ~w~. Obtain an Executive Board decision on the approach to be adopted with respect to the take-up of encryption facilities within NHS systems and the NwN, and on what would be considered suitable timescales over which the take-up should occur.

The Pilot Programme

A multi-stage pilot programme may be needed before major implementation is attempted. The initial tasks within this programme will involve specification and development work before pilot testing can begin. It is estimated that the first stage of the pilot would take between a year and is months to complete. The successive overlapping stages of the pilot could each take nine to twelve months to complete. Major steps within the first stage of the pilot would include.

Arrange for the necessary budget provisions for the Pilot programme to be made.
Identify the objectives of the piloting exercise and from the results identity suitable applications and areas of the network for involvement within the Pilot. It wilt be necessary to strike a balance between choosing applications and areas which are representative of the main problems which will be encountered in frill implementation, and ensuring that the pilot remains manageable. Consequently, there may be a need for more than one pilot stage, each successive one of increasing technical complexity~
Develop an overall plan for the pilot programme.
The preparation of a number of technical standards and specifications will be needed. wherever possible, these should be based on existing standards. The following will be required. key management standards specification for the key management systems at a trusted third party depending on the nature of the pilot implementation, the following may be required standards for cryptographically protected exchanges in the NWN an API specification for a standard cryptographic software architecture tool lit for each application involved in the pilot, a specification for adding the cryptographic capabilities.
Agree a contractual basis for the participation of both suppliers and users in each stage of the pilot.
Ensure the availability of appropriate types of cryptographic software and hardware products that might be required.
Develop the first stages of the key management infrastructure as necessary for the first stage of the pilot.
Design, develop, implement and test any modifications necessary to enable each of the applications and systems involved in the pilot to make use of encryption.
Carry out a security awareness programme for the users including any specific guidance necessary for users to understand and use the cryptographic facilities provided under the first pilot project. Develop the training needed for the operators and management of the pilot TTP.
Implement and run the first stage of the pilot.
Carry out a preliminary evaluation of the results of the pilot at the earliest feasible milestone. Use these results to plan any changes to the remainder of the first stage pilot programme.
Carry out a final evaluation at the end of the planned pilot programme and adapt the plans for successive pilot stages and the preliminary planning for final implementation, as needed in the light of the results.

Appendix - Algorithms and key management

This appendix describes the process by which the study has arrived at its recommendations regarding the encryption algorithm and key management infrastructure that should be used. We do not attempt in this report to provide the user with an introduction to the use of cryptography or to the measurement of its capabilities. There are a number of available texts and reference sources which make the subject accessible to the interested reader and which should be available in any good sized technical library.

Two entities exchanging encrypted data across the NWN will need to share common cryptographic keys whilst ensuring that the keys used for decrypting data are kept secret. The mechanisms for exchanging these keys securely mus~ as far as possible, be invisible to the users of the systems involved.

For data encryption, the NHS will need to use symmetric rather than asymmetric algorithms. This is to provide acceptable performance in software implementations, and compactness of code. Symmetric algorithms can also be used to provide message and data integrity protection, and source authentication, and can be used in strong methods of user authentication, but not for generating Digital Signatures.
Conventional symmetric algorithms that are in the public domain, for example, RC4 (40 bit equivalent key length - often found in Internet security products) or DES (56 bit equivalent key length - widely used throughout the Banking sector), would not be adequate to the NHS's needs. There are no stronger symmetric algorithms in the public domain which are not restricted in one way or another (by patent or by other controls) and which would, therefore, be available for use throughout the NHS.
The published E-mail security package PGP would not be suitable as a strategic solution to satisfy the requirement for NWN encryption. PGP is designed for the one way messaging environment and could not be used for interactive communications PGP uses an algorithm which is patent controlled (the IDEA algorithm for which the patent is held by a Swiss company ASCOM). Hence, the NHS would be tied to a single algorithm supplier which was both a commercial organisation and non-UK based PGP is available either unsupported as freeware or as a commercial version from a single supplier. Neither option would be attractive strategically to the NHS PGP does not define a mechanism for the convenient distribution of encryption keys. This would severely limit its suitability for such a large community as the MIS. It is also, for this reason, vulnerable to "man in the middle" attacks in which an attacker arranges for a sender of information to be provided with his public key in place of the public key of the intended destination of the information. The attacker is then able to decrypt the information and send it on to the true destination using the correct public key.

This problem can be overcome with the use of a Trusted Third Party (TTP), and, indeed, a Tm is required for the proposed solution. However; this means that PGP could not be used as a strategic solution in its current form. Its wide scale use would require the modification of the package by the supplier to include interfaces to a Tm infrastructure

PGP does not integrate well with standard office e-mail packages. For the non-technical user, PGP would require the development of a front-end to dc-skill its user interface. Again, this means that PGP could not be used as a strategic solution in its current form
CESG has also advised that there are significant security advantages to using unpublished algorithms rather than published algorithms. However, unpublished algorithms will be either proprietary, unaccepted by the cryptographic community, or strictly controlled by the governments that have developed them. Any one of these would make the algorithm either unacceptable or unavailable to the NHS.
The NHS is, therefore, in the constrained position of needing to use an encryption algorithm that is sufficiently strong for its protection needs but which can also be made available across the NHS as a whole and to the NHS's many systems suppliers. Until recently, no such algorithm existed to be used by the NHS. However, within the last 12 months, this situation has changed. CESG has responded to this SituatiOn, which the NHS shares with many other large organisations outside the government or Financial Services sectors, by developing an algorithm known as Red Pike. The recommendation from CESG, and supported by Zergo, would be that the NHS should use this algorithm to meet its data encryption needs.
Red Pike has been released only recently and a number of necessary National Policy decisions were made by CESG in the last months of 1995 relating to its distribution and use. Red Pike can be implemented in software as well as in hardware, and in a number of forms to facilitate its use with a variety of systems and on a variety of platforms. There are no standards covering the use of Red Pike. However; Red Pike has been designed to share a number of characteristics with DFS, for which there are many public standards. Hence Red Pike could easily be used in accordance with those standards. And Red Pike can be released in appropriate forms to the NHS's suppliers, including those that are not solely UK-based.
whenever a cryptographic algorithm is used for data encryption, one or more encryption keys will need to be exchanged or agreed between the two parties (the sender and the receiver) so that only the authorised receiver is able to decrypt traffic encrypted by the sender. This process is known as Key Management.
Among the users of the NHS-wide networking system, there will be many users of encryption and, for each user, potentially many other users for which it will require new or unique keys to ensure secure communication. Hence, for many of the users, and certainly when looking across the NHS community as a whole, there will be many keys to be managed. For this reason of very large scale, it will be essential for the NHS to have a Key Management infrastructure that includes the use of asymmetric key management methods.
This would exclude the use by the NHS of the most long-standing and, therefore, widely used key management standards (for example, the ANSI X9.17 standard). However, asymmetric key management methods have been used and well proved in large networks (many thousands of users) in the last five years, and suitable international standards are now in existence for these.
The D-H functionality (with or without KR capability) will allow two networked end-systems to agree a symmetric key for bilateral use. This key may be used as the Red Pike key for message encryption. Alternatively, it might better be used to protect (by encryption) a second Red Pike key, that key then being exchanged between the two end-systems and being the one used for message encryption.
This use of encryption keys to encrypt other encryption keys is a well established Key Management technique and can be used to allow the frequent and automatic changing of message keys without the overhead of renewing frequently the higher level D-H keys. Indeed, it is not unusual to have a multi-layered hierarchy of Symmetric keys allowing the key at the top of the hierarchy to be changed only rarely whilst the keys at the bottom of the hierarchy can be changed automatically with each and every message. The NHS should build in to its Key Management infrastructure the flexibility to allow this key hierarchy technique to be used wherever needed.
A D-H key management infrastructure could be used to manage asymmetric keys as well as symmetric keys. As was mentioned in the footnote to Point 6 above, the processes used by D-H can be extended simply to provide the DSA digital signature algorithm. DSA could be used for generating the necessary certificates for asymmetric keys, whether they were DSA keys or RSA keys, and according to whichever standard (for example, version 5 of X.509 standard) that was required. Consequently, the NHS would have the option of using its D-H key management infrastructure as the basis for the management of other keys as might be needed for any future interworking with other schemes, for example those which might be used in other European countries.
The solution outlined above will take some time to implement, in part because of the need to pilot the technology being introduced. It is appropriate, in this case, to consider what shorter term, non-strategic solutions might exist. The options to consider existing suitable COTS (Commercial off-the-shelf) products that use other algorithms besides Red Pike products that would be appropriate for only a limited range rather than all applications.
The general problem with COTS products which do not use Red Pike are that they are either not available for the NHS's use or, if they are, they do not have an adequate level of cryptographic strength. There is one specific product; PGP, which does not suffer from these drawbacks. That has been dismissed as not being a suitable strategic solution for the NHS (see earlier in this Appendix), and a number of those reasons would also limit its suitability as a short-term solution. There are a growing number of E-mail security products, either on or coming to the market, which address some of the shortcomings of PGP, and one of these (at least one, to Zergo's knowledge) has recently been upgraded to incorporate the Red Pike algorithm. That product would have the following advantages as an interim solution for the NHS.
- it is an E-mail security utility, and that would make it appropriate for a good proportion of the NHS's immediate need
- it already has Red Pike in it, increasing its compatibility with the recommended strategic solution
- it integrates with ordinary office E-mail systems (which addresses a major drawback of PGP)
- it works with a D-H key management layer (though a rather cut down version compared to the recommended strategic solution)
- it is available today.
This product should not be seen as a strategic solution for the NHS for many of the same reasons that PGP is not (see earlier in this Appendix), and those are.
- it is designed for messaging and could not be used for interactive communications there is only the one supplier
- it does not have a mechanism for the convenient distribution of encryption keys, which would limit its suitability for such a large community as the NHS.
However, it might have some value as a short term, interim solution for a limited range of applications, and would warrant further investigation for adoption in this capacity. That further investigation should also identify any other such products which may be on or about to enter the market.